add operator impl #7
Conversation
| @@ -0,0 +1,6 @@ | |||
| fiftyone: | |||
| version: ~0.21.0 | |||
There was a problem hiding this comment.
This defines the compatible version using semver matchers.
There was a problem hiding this comment.
We probably need a way to also define the teams compatible version.
There was a problem hiding this comment.
Every version of the Teams SDK has a corresponding OSS version (a range of compatible OSS versions, in fact), so we could require all users to "speak" OSS versions for now
| @@ -0,0 +1,6 @@ | |||
| fiftyone: | |||
| version: ~0.21.0 | |||
| name: '@voxel51/fiftyone-docs-search' | |||
There was a problem hiding this comment.
I think we should encourage this pattern, which is to match the github repo name to the plugin name. In theory we could also split this and then every "name" in this file is technically prefixed with the org name:
org: voxel51
name: fiftyone-docs-search
operators:
- name: search-docs
There was a problem hiding this comment.
I think we should encourage this pattern, which is to match the github repo name to the plugin name. In theory we could also split this and then every "name" in this file is technically prefixed with the org name:
org: voxel51 name: fiftyone-docs-search operators: - name: search-docs
I prefer this version. Typing @voxel51/fiftyone-docs-search for plugin name in zoo methods is an unnecessary pain
| class SearchDocs(foo.DynamicOperator): | ||
| def __init__(self): | ||
| super().__init__( | ||
| "@voxel51/search-docs", |
There was a problem hiding this comment.
Note for anyone curious. This name match match the operator name defined in yaml. As far as the teams runtime is concerned, it will only refer to what is listed in the fiftyone.yml, not that it reads from this file.
| def resolve_input(self, ctx): | ||
| inputs = types.Object() | ||
| inputs.str("query", label="Query", required=True) | ||
| return types.Property(inputs) |
There was a problem hiding this comment.
resolve_input returns a Property to allow for customizing the entire form view the property.view. This is because the entire form is actually defined by a Property of the operators definition (which is a types.Object).
In the operator type system, base types like object do not have ui metadata associated with them, since they should be re-usable and generic (in both senses of the word eg. List(String) - List is a "Generic" type aka template type.)
| op = SearchDocs() | ||
| foo.register_operator(op) | ||
|
|
||
| def unregister(): |
There was a problem hiding this comment.
We may be able to omit this and auto-unregister anything defined in the yaml.
There was a problem hiding this comment.
I think we should find a way to auto-unregister w/o needing this function
| op = None | ||
|
|
||
| def register(): | ||
| op = SearchDocs() |
There was a problem hiding this comment.
This doesn't update the top-level op object. You'd have to include global op in order to do that.
https://en.wikipedia.org/wiki/Variable_shadowing
|
|
||
| op = None | ||
|
|
||
| def register(): |
There was a problem hiding this comment.
I think we could auto-register as well. One way to do that would be to import this module and then automatically register all classes in the namespace that derive from foo.Operator. Or, if we wanted to be explicit, we could include the names of the operator(s?) in the yaml file that should be registered.
No description provided.